Hi
你們的 Review Meeting 是不是常常按部就班、萬年不變呢？今天，筆者要帶大家一探我們團隊曾經大膽嘗試過的幾種有趣的進行方式喔！

創意流程來襲

要攻破這個挑戰，首先得了解，這場會議到底在追求什麼目標？是哪些角色的大明星會出席？人數是不是多到難以控制呢？接下來，就讓我根據不同的情境，大方分享我們團隊的創意經驗和實用做法啦！

當場上只有1~2個團隊時，我們會選擇讓這些團隊依序秀出他們這個 Sprint 的精彩成果。首先，得讓大家明白這個 Sprint 追求的目標是什麼也就是在 Sprint 初期訂定的 Sprint Goal，然後才能開始一一亮相。每個 Story 都應該要以全方位的 End to End 方式呈現，讓大家有機會發問並給予團隊以及 Product Owner 珍貴的回饋，尤其是針對產品的各個細節。對於 Sprint Goal 之後會在專門拉一天來分享，敬請期待。

這時，有人可能會好奇：“這樣是不是就不是每個人都能展示到自己的成果了？”
對此，我們得重新審視一下開發團隊的真義——開發團隊應該是一個能夠跨領域合作的自主團隊。因此，我們應該從團隊的角度來展現成果，而不是個人，畢竟每個 Story 都是大家一起努力完成的。

秘密武器大公開

除此之外，我還有更多實用小技巧和創意方法要和大家分享呢：

1. 分組進行：當參與的夥伴越來越多時，分組進行會是個不錯的選擇。就像我們之前提到的，每個 Story 都是團隊的共同努力，所以團隊中的每個成員都應該有展現成果的能力。

2. 破除知識的詛咒：讓展示的人不是開發的團隊成員。例如，A團隊的 Story 由B團隊來展示，A團隊則在一旁進行解說，之後再進行角色互換。這樣有時會意外發現開發團隊的小盲點，有些看似理所當然的操作，對其他人來說卻可能難以理解和操作。

3. 園遊會模式：當開發團隊人數眾多時，我們可以像辦園遊會一樣，設定時間讓大家輪流參觀不同團隊的成果，最後再聚在一起進行分享交流。

非開發團隊的加入

而且，Review Meeting 的門檻其實是很低的，並不是只有開發團隊才能加入。事實上，來自各個領域的夥伴們都會分享他們在這個 Sprint 中的新成果和進展。例如，設計團隊會展現他們手上正在進行中的創意設計，不管是初期的草圖還是尚未敲定的設計圖，都會拿出來和大家一同討論。這不僅讓我們了解到設計的方向和進度，還能從不同的角度收集意見和反饋，進一步完善設計。

同樣，Product Owner 也會分享一些關於產品的新動態，像是上一個 Sprint 中新功能的效能如何，以及未來對產品的展望和計畫。這不僅讓大家對產品的未來有了更清晰的畫像，也提供了一個讓團隊討論產品可行性、時間估計和價值的平台。

透過這樣的交流和分享，每個團隊成員都能更全面地了解產品的現狀和未來走向，並有機會從不同角度對產品提出寶貴的見解，推動產品不斷向前進化。

這些就是我們常常使用的一些實用策略和心得，希望能夠為大家帶來靈感和幫助。畢竟，開會也可以是一場既有趣又富有成效的交流體驗！

讓我們一起動起來，創造更多有趣和有意義的 Review Meeting 吧！

預告：[Page13]Review meeting 常見的疑問

明天將會更深入的分享一些筆者過去常被詢問的一些疑問，例如『是否應深入技術細節』、『參與的人倒底應該有哪些角色』、『如何提高大家對於產品的關注』